SQL Azure : Security - Access Control

1. Authentication (AUTHN)

AUTHN is a process that verifies you're indeed who you say you are. In SQL Server, the AUTHN process is done through one of two mechanisms: network credentials (or Security Support Provider Interface [SSPI]) or SQL Server credentials. Connection strings must specify which AUTHN is being used. And when you use SQL Server AUTHN, a password must be provided before attempting to connect, either by a user at runtime or in a configuration file.

Keep the following items in mind when you're considering AUTHN with SQL Azure:

• No network authentication. Because SQL Azure isn't on your network, network AUTHN isn't available. This further means you must use SQL AUTHN at all times and that you must store passwords in your applications (in configuration files, preferably). You may want to store your passwords encrypted. Although you can encrypt sections of your configuration files in Windows using the aspnet_regiis.exe utility, this option isn't available in Windows Azure. So, you can use one of the encryption methods presented earlier to encrypt and decrypt the SQL Azure connection string if necessary.

• Strong passwords. SQL Azure requires the use of strong passwords. This option can't be disabled, which is a good thing. A strong password must be at least eight characters long; must combine letters, numbers, and symbols; and can't be a word found in a dictionary.

• Login name limitations. Certain login names aren't available, such as sa, admin and guest. These logins can't be created. You should also refrain from using the @ symbol in your login names; this symbol is used to separate a user name from a machine name, which may be needed at times.

2. Authorization (AUTHZ)

Authorization gives you the ability to control who can perform which actions after being authenticated. It's important to define a good AUTHZ model early in your development cycle, because changing access-control strategy can be relatively difficult.

Generally speaking, a strong AUTHZ model defines which users can access which objects in the database. This is typically performed in SQL Azure and SQL Server by defining relationships between logins, users, schemas, and rights.

2.1. Creating Logins and Users

In SQL Azure, you must be connected to the master database to manage your logins. The CREATE LOGIN T-SQL statement is partially supported. Also, remember that you must use a strong password when creating logins.

SQL Azure offers two new roles:

• LoginManager role. Grants a user the ability to create new logins in the master database

• DBManager role. Grants a user the ability to create new databases from the master database

The following code shows how to create a login and grant that login the LoginManager role:

CREATE LOGIN MyTestLogin WITH PASSWORD='MyT3stL0gin'
GO
CREATE USER MyTestLoginUser FROM LOGIN MyTestLogin
GO
EXEC sp_addrolemember 'loginmanager', MyTestLoginUser
GO

Note that CREATE USER statement creates a user in the master database because you haven't connected to another database. Creating the MyTestLogin user in the master database is precisely what you want because you can only create login accounts from the master database.

To allow the MyTestLogin account to also access another database, connect to the desired database in SQL Azure using another login and run the CREATE USER statement again. Now the MyTestLogin account can connect to another database.

2.2. Schemas

A schema is a container that holds database objects; schemas reside inside a database. Schemas are part of the three-part naming convention of database objects; they're considered namespaces. Each object in a schema must have a unique name.

By default, objects created are owned by the DBO schema. For example, the CREATE TABLE statement showed previously for the UserProperties table uses DBO as the schema owner (schema_id is always 1 for DBO). See Figure 1.

Right now, the new user MyTestLoginUser can't read from this table. Attempting to issue a SELECT statement against UserProperties returns a SELECT permission denied error. So, you have a choice: you can either give that user account SELECT permission or create a schema for that user and assign the SELECT permission to the schema.

Figure 1. Viewing an object's schema ownership

It's usually much easier to manage access rights through schemas instead of users directly. To do this properly, you need to change the ownership of the UserProperties table to a new schema (other than DBO) and then assign access rights to the schema.

To create a new schema, you must be connected to the desired user database where MyTestLoginUser has been created. Then, run the following statement:

CREATE SCHEMA MyReadOnlySchema AUTHORIZATION DBO

At this point, a schema as been created; it's owned by DBO. You now need to change the ownership of the UserProperties table to MyReadOnlySchema:

ALTER SCHEMA MyReadOnlySchema TRANSFER DBO.UserProperties

The table now belongs to the schema, as shown in Figure 2.

Figure 2. Viewing the new schema owner

However, you aren't done just yet. MyTestLoginUser can no longer see the table. Issuing a select statement on the table returns an Invalid object name message, as shown in Figure 3.

Figure 3. Error when the user can't see an object

The default schema of MyTestLoginUser is DBO, as shown in Figure 4. The default schema of a user is the schema that's used if none is specified in a T-SQL statement. To make it easier on developers, change the default schema to MyReadOnlySchema, so it doesn't have to be specified in T-SQL statements.

Figure 4. Schema owner of a login

To change the user's default schema, you need to execute this statement:

ALTER USER MyTestLoginUser WITH DEFAULT_SCHEMA = MyReadOnlySchema

Now that the user has MyReadOnlySchema as its default schema, it can see the objects owned by that schema directly, without having to specify the object owner. However, you haven't set the access rights yet. Let's grant SELECT rights to MyTestLoginUser:

GRANT SELECT ON SCHEMA :: MyReadOnlySchema TO MyTestLoginUser

The following statement works again for the MyTestLoginUser account:

SELECT * FROM UserProperties

Why did you go through all this trouble? Because creating your own schemas is a great way to simplify access control by granting rights to schemas instead of objects directly. In a way, schemas can be used as a group, like a Windows Group, on which rights are granted or denied.

Figure 5 shows how you've switched the security model around for greater flexibility and control.

Figure 5. Moving to a security model through schemas

3. Firewall

SQL Azure comes with its own firewall, which you can configure directly from the SQL Azure portal. You can also view and change firewall rules in T-SQL. Let's take a quick look at the available SQL statements.

To view the current firewall rules, execute this statement:

SELECT * FROM sys.firewall_rules

You can see that each rule has a name; the name is used as a unique key. The sp_set_firewall_rule command allows you to add a new rule.

It may take a few minutes for the new rules to take effect. For example, the following statement adds a new rule called NewRule. Notice that the first parameter must be a Unicode string:

sp_set_firewall_rule N'NewRule', '192.168.1.1', '192.168.1.10'

To delete a rule, run the following statement:

sp_delete_firewall_rule N'NewRule'